Summary

• fix a panic in flare-edge-cli deploy --var ... when the loaded project config has a nil bindings.vars map
• extract deploy var merging into a small helper that initializes both config maps before assignment
• add a regression test that reproduces the nil-map shape from the reported failure

Problem

A user reported that running a deploy with one or more --var KEY=value flags could crash the CLI with:

panic: assignment to entry in nil map

The panic occurred in internal/service/deploy/service.go while handling deploy-time variable overrides.

Root Cause

The deploy path initialized wranglerCfg.Vars when it was nil, but it also wrote the same entries into project.Bindings.Vars without checking whether that map had been initialized.

That means projects loaded from disk with a missing or nil bindings.vars field could panic as soon as --var was used, even though the equivalent Wrangler config path had already been guarded.

Fix

This PR:

• moves deploy-time var application into a dedicated applyVars(...) helper
• initializes both wranglerCfg.Vars and project.Bindings.Vars when needed
• skips malformed --var entries instead of touching either map

The behavior stays the same for valid inputs, but the nil-map panic is removed.

Testing

• go test ./internal/service/deploy
• go test ./...

Added regression coverage in internal/service/deploy/service_test.go to verify that:

• nil maps are initialized before assignment
• valid KEY=value pairs are applied to both config models
• malformed entries are ignored

User Impact

After this change, deploy commands like:

flare-edge-cli deploy --path services/telegram-adapter --var "ORCHESTRATOR_URL=https://threadline-orchestrator.paoloanzani.workers.dev" --json

should no longer panic when the project config was loaded with an empty or omitted bindings.vars map.